1. Technical Field
The present invention is related to a method and system to be utilized in data communications. In particular, the present invention is related to a method and system to be utilized in data communications involving at least one data communications network. Yet still more particularly, the present invention is related to a method and system, to be utilized in data communications involving at least one data communications network having at least one network node.
2. Description of the Related Art
Data communications is the transfer of data from one or more data sources to one or more data sinks that is accomplished (a) via one or more data links between the one or more sources and one or more sinks, and (b) according to a protocol. Weik, Communications Standard Dictionary 203 (3 ed. 1996). A data link is the means of connecting facilities or equipment at one location to facilities or equipment at another location for the purpose of receiving the data. Weik, Id. 206 (3 ed. 1996). A protocol, in communications, computer, data processing, and control systems, is a set of formal conventions that govern the format and control the interactions between two communicating functional elements in order to achieve efficient and understandable communications. Weik, id. 770 (3 ed. 1996).
A data communications network is the interconnection of three or more communicating entities (e.g., data sources and/or sinks) over one or more data links. Weik, Id. 618 (3 ed. 1996). The branch of science and technology that is devoted to the study and analyses of the configurations and properties of networks makes use of what are known as network topologies. Weik, Id. 622 (3 ed. 1996). A network topology is typically a graphical representation of the specific logical arrangement, from a communications standpoint, of elements in a network, irrespective of such network elements' actual physical connection. In the art and science of network analysis, different networks are distinguished by their different network topologies.
In network topology, each communicating entity in a network is depicted as a graphical point, or node. These nodes are abstract representations of locations in an actual physical network at which one or more data transmission lines are interconnected. Weik, Id. 622 (3 ed. 1996).
There are multitudinous known network topologies (e.g. mesh, star, fully connected, etc., and hybrids of such known network topologies). One such well-known network topology is the star network topology, which can be utilized to illustrate a problem that exists generally in the field of data communications involving networks having nodes.
A star network topology is a radial (starlike) configuration of communications network nodes such that (a) each endpoint node is connected via a single branch directly to the central node that serves as a central distribution node, and (b) each endpoint node can communicate with any other node only via the central node and two branches. The central node serves as a distribution node to all the endpoint nodes, including the originating node, or to selected endpoint nodes, depending upon whether the central node is an active or passive node. Weik, Id. 625 (3 ed. 1996).
FIG. 1 illustrates a star network topology. Shown is central node 100. Connected to central node 100 are endpoint nodes 102-116. These endpoints are connected to central node 100 via data links 122-136, respectively. The topology of the network makes clear that all communications between endpoints must transit central node 100.
In operation, central node 100 receives packetized data (in its most generic sense packetized data typically consists of a message field, a source field indicates the source node of the packetized data, and a destination field indicates the destination node (or data sinks) of the packetized data) from endpoint nodes 102-116 over their respective data links. Upon reception of such packetized data, central node 100 reads the destination field, determines which data link or links the packetized data must be sent over to reach the destination indicated in the destination field, and then subsequently sends the packetized data over the appropriate data link or links. Central node 100 must do the foregoing (receive the packetized data, read the destination field, and then transmit the packetized data over the appropriate link) for each unit of packetized data received.
If central node 100 is to send the data over only one data link, central node 100 is said to be engaging in "unicast" (i.e., transmitting the packetized data unit to only one ("uni") station). If central node 100 to send the data over more than one data link, central node 100 is said to be engaging in "multicast" (i.e., transmitting the packetized data unit to multiple ("multi") data stations).
In the event that a packetized data unit is addressed to one or more destination nodes which utilize the same data link protocol (i.e., "speak the same language") as the source node for the packetized data unit, central node 100 need merely receive the packetized data unit from the source node and transmit copies of it to the one or more destination nodes. This function is typically referred to as "bridging," because what the node is actually doing is serving as a "bridge" between two logically connected nodes (i.e., nodes utilizing the same protocol) which just happen to be physically disconnected.
In the event that a packetized data unit is addressed to one or more destination nodes which utilize different data link protocol(s) (e.g., do not "speak the same language") as a source node of each and every packetized data unit, then it is necessary for central node 100 to serve as a "translator" and make sure that each packetized data unit is modified such that it utilizes the protocol appropriate to the destination node to which it is destined. Thus, in this instance central node 100 engages in protocol translation and attendant packetized data modification prior to the frame being transmitted from the node over a particular data link. This function is typically referred to as "routing," because what the node is actually doing is serving to "route" packetized data units between two physically and logically (e.g., nodes that do not utilize the same protocol) disconnected nodes.
The foregoing discussion has utilized a central node in a star network to illustrate points common to all network nodes connecting three or more other network nodes (i.e., for each node in a network central to three or more other nodes). Those common points are that for each such node connecting three or more other nodes, in order to function effectively such central node, upon receipt of a packetized data unit that is to be transmitted through the central node, must: (1) determine whether the packetized data unit is to be unicast or multicast (i.e., must determine the data link or links over which the packetized data unit must be transmitted); (2) produce a copy of the packetized data with respect to each data link over which the packetized data unit is to be transmitted; (3) with respect to each copy of the packetized data unit which is to be transmitted, determine if protocol translation for such copy is necessary prior to the packetized data unit being transmitted from the node; and (4) after any necessary protocol translation and attendant packetized data unit modification, transmit a copy of the packetized data over each data link appropriate to the destination of the copy.
The foregoing dealt with the circumstance wherein only one source node was attempting to transmit to one or more destination nodes. It is common for several end stations to desire to communicate with other end stations virtually simultaneously. In such situations, central node 100 is called upon to do all the foregoing functions for several different discrete packetized data units.
In old-style nodes performing the foregoing noted functions which were illustrated via reference to central node 100, the foregoing noted functions were achieved by buffering (placing in temporary storage) one or more of the packetized data units, and then processing the stored data units one at a time. Another way to state this is that the packetized data units arriving virtually simultaneously were enqueued (made to wait in line) and would only be processed after the packetized data units ahead of them in the queue had been processed. That is, the four different logical steps noted above (i.e., determination of unicast/multicast, copy packetized data unit(s), engagement in any necessary protocol translation, and subsequent transmission of all the copies from the node over the appropriate data links) were engaged in for one particular packetized data unit, and after such processing was completed, the next data unit in the queue was attended to.
This need for enqueuing arose from the fact that in old-style nodes there was only one processor (or "thinker"), and that processor could only process on one packetized data unit at a time. Thus, if more than one packetized data unit appeared at central node 100 virtually simultaneously, many of such packetized data units would have to "wait their turn" until the processor was able to process them.
As network data traffic has increased, it has been found that such enqueuing and sequential processing has began to result in unreasonable communication delays (i.e., the wait in line, or in the "queue," became too long for the communications needs of particular endpoint nodes to be satisfied). However, as has been noted, such a wait is inherent in the very nature of a network node, when such network node is both unicast and multicast capable.
It is desirable to preserve the ability of network nodes to engage in both unicast and multicast. However, it is also desirable to decrease the latency (waiting) experienced by packetized data units transiting such a unicast and multicast capable node.
In light of the foregoing, it is apparent that a need exists for the present invention: a method and system to increase the efficiency of packetized data unit transmission through network nodes.